Witam,
Czytałem nieraz historie o tym, że jeśli chcę przeskanować sieć, która stoi
za firewallem, który nie wpuszcza pingów i blokuje ruch wchodzący, to mogę
próbować łączyć się z poszczególnymi kompami. Jeśli taki komp istnieje, to
usłyszę ciszę; jeśli nie istnieje -- usłyszę "ICMP host unreachable".
Zestawiłem więc na próbę taką sieć:
+-----(3)
/
(1)----(2)---+
\
+-----(4)
(1) to komp intruza, (2) to firewall z dwiema kartami sieciowymi, (3) to
serwer www, (4) to taki sobie koleś.
Założenia: z zewnątrz ma być dostępny tylko port 80 serwera www, z kolei
koleś z (4) może serfować po www (więc może tylko nawiązywać połączenia
wychodzące na port 80).
W związku z tym polecenia dla iptables, które wydałem na (3), wyglądały tak:
# trójka, czyli serwer www
iptables -A FORWARD -d 172.16.193.129 -p TCP -m state \
--state ESTABLISHED -j ACCEPT
iptables -A FORWARD -d 172.16.193.129 -p TCP --destination-port 80 -j ACCEPT
iptables -A FORWARD -s 172.16.193.129 -p TCP -m state \
--state ESTABLISHED -j ACCEPT
# czwórka, czyli zwykły koleś
iptables -A FORWARD -d 172.16.193.130 -p TCP -m state \
--state ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 172.16.193.130 -p TCP -m state \
--state ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 172.16.193.130 -p TCP --destination-port 80 -j ACCEPT
iptables -A FORWARD -j DROP
Rzeczywiście, kiedy z zewnątrz (czyli z jedynki) skanuję nmapem tę sieć
widzę tylko serwer www. Próbuję wysłać pakiet syn do czwórki:
# sendip 172.16.193.129 -p ipv4 -is 10.10.10.88 -id 172.16.193.129 \
-it 2 -p tcp -td 80
Nasłuchuję (cały czas na jedynce) tcpdumpem co się dzieje -- oczywiście
cisza.
Dla odmiany tak samo puszczę syn do nieistniejącego kompa 172.16.193.140:
# sendip 172.16.193.140 -p ipv4 -is 10.10.10.88 -id 172.16.193.140 \
-it 2 -p tcp -td 80
No i kicha, nie dostałem żadnego "ICMP host unreachable". Oczywiście jak
wyczyściłem iptables
# iptables -F
to wysyłanie syna na nieistniejący komputer 172.16.193.140 powoduje, że
firewall posyła mi "ICMP host unreachable".
No i teraz pora na pytanie. Oczywiście rozumiem, czemu przy takiej
konfiguracji firewalla mój sprytny plan nie działa; to sprawka:
iptables -A FORWARD -j DROP
Ale w takim razie przy jakiej konfiguracji firewalla taki sposób ma sens?
Macie jakąś koncepcję?
i będziesz miał, co chcesz.
i będziesz miał, co chcesz.
Moje pytania brzmią:
(1) Na zdrowy rozum, ponieważ pakiety ICMP host unreachable tworzone są
wewnątrz rutera (komputera 2), więc nie powinny przechodzić przez łańcuch
FORWARD; w związku z czym reguła iptables -A FORWARD -j DROP nie powinna
mieć na nie wpływu. A jednak widzę, że ma wpływ. Dlaczego?
(2) Skoro, jak widać, przy najnormalniejszej konfiguracji firewalla
(DROPujemy wszystko, co nie jest jawnie dozwolone) ten sposób nie działa,
to czy wogóle są jakieś nieakademickie sytuacje, kiedy ten sposób ma sens?
Ma wpływ na pakiety TCP SYN.
Z drugiej strony oznacza to, że sama koncepcja tej metody jest błędna --
dałoby się ją stosować tylko w jakichś bardzo dziwnych przypadkach, przy
dziwnie skonfigurowanych firewallach...
Aha, Âżeby ukonkretniĂŚ: przy tym wszystkim opieram siĂŞ na tekÂście Ofira
Arkina: http://www.sys-security.com/archive/papers/ICMP_Scanning_v2.5.pdf
ZwÂłaszcza na tym fragmencie:
<cytat
4.O Inverse Mapping Using ICMP (ECHO & ECHO Reply) Inverse Mapping
is a technique used to map internal networks or hosts that are
protected by a filtering devices/firewall. Usually some of those
systems are not reachable from the Internet. We use routers, which
will give away internal architecture information of a network, even
if the question they were asked does not make any sense, for this
scanning type. We compile a list of IP's that list what is not
there and use it to conclude were things probably are.
A router looks at the IP address and makes decisions based on that solely.
We use two ICMP message types in order to use this technique. ICMP
ECHO and ICMP ECHO Reply. We send a number of ICMP ECHO / ICMP ECHO
Reply datagrams to different IP's we suspect are in the IP range of
the network we are probing. When a router, either an exterior or
interior, gets those ICMP message types for further processing, it
looks at the IP address and makes decisions of routing based on it
solely. When a router gets a datagram with an IP which is not used
in the IP space / network segment of the part of the probed network
he serves, the router will elicit an ICMP Host Unreachable
(Generated by a router if a route to the destination host on a
directly connected network is not available - does not respond to
ARP) or ICMP Time Exceeded (Because the amount of time the Router
waits for determining the destination host is unavailable have not
been reached yet, but the TTL timer have turned O because of the
time we wait for an answer) error message(s) back to the originator
of the datagram. If we do not get an answer about a certain IP we
can assume this IP exist inside the probed network.
We are using the ICMP ECHO Reply datagrams because most of the
firewalls will let them pass through.
</cytat
Co prawda tu facet uÂżywa ICMP echo request, ale tak wogóle nie próbowaÂłem
tego robiĂŚ, bo imo takÂą sytuacjĂŞ, kiedy jakiÂś firewall wpuszcza wchodzÂące
ping requesty a blokuje wychodzÂące ping replaje (a tak, jak widzĂŞ, zakÂłada
Ofir) to juÂż caÂłkiem siĂŞ w Âżyciu nie spotka. Czy siĂŞ mylĂŞ?
Nie generowanie icmpów tylko ogólnie analizowanie pakietów (...)